Summary

Workaround for Thread 1 displaying incorrect backtraces when debugging Zephyr applications.

Problem

When GDB connects to OpenOCD with RTOS awareness:

1. GDB reads and caches live CPU registers
2. GDB creates implicit "Thread 1" with these cached registers
3. Later, GDB requests thread list from OpenOCD
4. OpenOCD returns threads in kernel order (e.g., "stats" thread first)
5. GDB assigns "stats" to Thread 1
6. But Thread 1 already has the idle thread's registers cached

Result: Thread 1 "stats" shows idle's backtrace (arch_cpu_idle()).

Fix

Reorder the thread list so the current thread is always first. This ensures:

• Thread 1 = current thread = the thread actually running on CPU
• Cached registers correctly belong to Thread 1

This is a Workaround

This fix addresses the symptom, not the root cause. A proper fix would require changes to GDB:

• GDB could invalidate cached registers when it receives thread info and discovers which thread was actually running
• Or the RSP protocol could be extended to provide thread context before GDB caches registers

Since GDB protocol changes would require upstream GDB maintainer buy-in and could take significant time, this workaround provides immediate relief. The resulting behavior (Thread 1 = current thread) also matches most users' expectations.

Verification

Before:

* 1    Thread 0x3fcb6cd0 "stats"     arch_cpu_idle()  ← WRONG frame!
  13   Thread 0x3fcb7cf8 "idle"      _switch_restore_pc()

After:

* 1    Thread 0x3fcb7cf8 "idle"      arch_cpu_idle()  ← Correct!
  2    Thread 0x3fcb6cd0 "stats"     _switch_restore_pc()

Related

This complements PR #390 which fixes register values for non-current threads.
Both issues were discovered while debugging Zephyr on ESP32-S3.